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Abstract 


This document defines several subcodes for the BGP Cease NOTIFICATION 
message that would provide more information to aid network operators 
in correlating network events and diagnosing BGP peering issues. 


1. Introduction 


This document defines several subcodes for the BGP Cease NOTIFICATION 
message that would provide more information to aid network operators 
in correlating network events and diagnosing BGP peering issues. It 
also recommends that a BGP speaker implement a backoff mechanism in 
re-trying a BGP connection after the speaker receives a NOTIFICATION 
message with certain CEASE subcode. 


2. Specification of Requirements 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC-2119]. 
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3.  Subcode Definition 


The following subcodes are defined for the Cease NOTIFICATION 
message: 


Subcode Symbolic Name 


Maximum Number of Prefixes Reached 
Administrative Shutdown 

Peer De-configured 

Administrative Reset 

Connection Rejected 

Other Configuration Change 
Connection Collision Resolution 
Out of Resources 


AAINDUBWNE 


4. Subcode Usage 


If a BGP speaker decides to terminate its peering with a neighbor 
because the number of address prefixes received from the neighbor 
exceeds a locally configured upper bound (as described in [BGP-4]), 
then the speaker MUST send to the neighbor a NOTIFICATION message 
with the Error Code Cease and the Error Subcode "Maximum Number of 
Prefixes Reached". The message MAY optionally include the Address 
Family information [BGP-MP] and the upper bound in the "Data" field, 
as shown in Figure 1, where the meaning and use of the <AFI, SAFI> 
tuple is the same as defined in [BGP-MP], Section 7. 


4------------------------------- + 
| AFI (2 octets) | 
4------------------------------- + 
| SAFI (1 octet) | 
4------------------------------- + 
| Prefix upper bound (4 octets) | 
4------------------------------- + 


Figure 1: Optional Data Field 


If a BGP speaker decides to administratively shut down its peering 
with a neighbor, then the speaker SHOULD send a NOTIFICATION message 
with the Error Code Cease and the Error Subcode "Administrative 
Shutdown". 


If a BGP speaker decides to de-configure a peer, then the speaker 


SHOULD send a NOTIFICATION message with the Error Code Cease and the 
Error Subcode "Peer De-configured". 
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If a BGP speaker decides to administratively reset the peering with a 
neighbor, then the speaker SHOULD send a NOTIFICATION message with 
the Error Code Cease and the Error Subcode "Administrative Reset". 


If a BGP speaker decides to disallow a BGP connection (e.g., the peer 
is not configured locally) after the speaker accepts a transport 
protocol connection, then the BGP speaker SHOULD send a NOTIFICATION 
message with the Error Code Cease and the Error Subcode "Connection 
Rejected". 


If a BGP speaker decides to administratively reset the peering with a 
neighbor due to a configuration change other than the ones described 
above, then the speaker SHOULD send a NOTIFICATION message with the 
Error Code Cease and the Error Subcode "Other Configuration Change". 


If a BGP speaker decides to send a NOTIFICATION message with the 
Error Code Cease as a result of the collision resolution procedure 
(as described in [BGP-4]), then the subcode SHOULD be set to 
"Connection Collision Resolution". 


If a BGP speaker runs out of resources (e.g., memory) and decides to 
reset a session, then the speaker MAY send a NOTIFICATION message 
with the Error Code Cease and the Error Subcode "Out of Resources". 


It is RECOMMENDED that a BGP speaker behave as though the 
DampPeerOscillations attribute [BGP-4] were true for this peer when 
re-trying a BGP connection after the speaker receives a Cease 
NOTIFICATION message with a subcode of "Administrative Shutdown", 
"Peer De-configured", "Connection Rejected", or "Out of Resources". 
An implementation SHOULD impose an upper bound on the number of 
consecutive automatic retries. Once this bound is reached, the 
implementation would stop re-trying any BGP connections until some 
administrative intervention, i.e., set the AllowAutomaticStart 
attribute [BGP-4] to FALSE. 


5. IANA Considerations 


This document defines the subcodes 1 - 8 for the BGP Cease 
NOTIFICATION message. Future assignments are to be made using either 
the Standards Action process defined in [RFC-2434], or the Early IANA 
Allocation process defined in [RFC-4020]. Assignments consist of a 
name and the value. 


6. Security Considerations 


This extension to BGP does not change the underlying security issues 
inherent in the existing BGP. 
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